6. WORKFLOWS

Using the same behind-the-scenes plumbing, you can now easily author and upload a declarative workflow to Office 365, and the workflow runs in the Windows Azure Workflow execution host completely outside of the SharePoint server farm. The workflow running in Windows Azure can then communicate back to SharePoint via the same core remote access technologies you saw in cloud-based apps such as CSOM, REST, and OAuth.

Challenges with Workflows in SharePoint 2010

If you remember, workflow was first introduced to the platform in SharePoint 2007 via Workflow Foundation 3.0. From an architectural perspective, workflows weren’t much different in SharePoint 2010 because the platform leveraged Workflow Foundation based on the .NET Framework 3.5 SP1.

Think of workflow in SharePoint 2010 in four primary scenarios:

• Scenario 1 — A power user builds a declarative workflow in SharePoint Designer 2010 and deploys it to SharePoint 2010. Declarative workflows contain no custom code and are strictly serial in nature (no support for state machine workflows).
• Scenario 2 — A power user builds a declarative workflow in SharePoint Designer 2010 and engages a developer to extend the workflow programmatically in Visual Studio 2010. This could be because of one of the following limitations in SharePoint Designer Workflows:
  • Implementation of custom business logic
  • Calling of SharePoint APIs
  • Calling of external systems (web services, feeds, and databases)
• Scenario 3 — A developer builds custom activities in Visual Studio 2010 and wraps them in actions for use in SharePoint Designer 2010. Those actions can then be used by power users who own the workflow business logic to be used in their declarative workflows.
• Scenario 4 — A developer builds a programmatic workflow in Visual Studio 2010 and packages it for deployment. In this scenario, all development is done in Visual Studio 2010.

Although the preceding scenarios cover most customer needs and fulfills their requirements, the workflow technology had some limitations. Now look at them:

• Scalability — Unlike many workloads that followed the SharePoint 2010 service application model for better scalability and tenancy support, workflow was not a true service in SharePoint 2010. As a result, customers can have only one workflow execution host per SharePoint 2010 farm, shared between all web applications and tenants.
• Stability and performance — SharePoint 2010 workflows are frequently hydrated and dehydrated between different tiers of the farm. An unhappy workflow or too many running instances can considerably impact the farm performance and its availability.
• High-privileged context — Workflows execute under the security context of the site’s application pool as a super user. This is not preferable in many use cases in which the security context of the user who initiated the workflow is needed. For example, Created By and Modified By fields on a workflow payload are always shown as a System Account. 
• On-premise deployments — Because workflows run as a super user in SharePoint 2010, sandboxed solutions cannot be used to host a programmatic workflow. Your only option in sandboxed solutions is to deploy a workflow action that later can be used in SharePoint Designer 2010.
• Flexibility — SharePoint 2010 is tightly coupled with a specific version of .NET Framework and Windows Workflow Foundation, so workflow developers cannot harness the latest workflow technologies from Microsoft. Again, that’s an expected result when you tightly couple a product to a specific version of a given technology.

Workflow Architecture in SharePoint 2013

SharePoint 2013 takes a different approach to workflow than its predecessor. In SharePoint 2013, workflow (the technology) is now treated as a true service. This means SharePoint workflows no longer run in SharePoint servers; instead, the execution is handled by Windows Azure Workflow on a separate server.

Windows Workflow Foundation 4.0 and .NET Framework 4.5 are the base to empower this new architecture. They both have been substantially redesigned from earlier versions. Figure 9 illustrates the workflow platform technology stack in SharePoint 2013.

FIGURE 9

The focus in SharePoint 2013 workflows is to build workflows declaratively. This is different from SharePoint 2010 where power users use SharePoint Designer to build declarative workflows and developers use Visual Studio to build programmatic workflows.

All out-of-the-box SharePoint 2013 workflows are now declarative, and the new workflows you build either by using SharePoint Designer 2013 or Visual Studio 2013 will also be declarative.

By making all SharePoint 2013 workflows declarative, you can use sandboxed solutions to deploy your workflow in its entirety. This is different than SharePoint 2010 where you could deploy workflow actions only using sandboxed solutions.

Microsoft recommends that you build new workflows using the SharePoint 2013 workflow model and push the custom code to web services. Building a programmatic workflow all from scratch is still possible, but for two reasons it may not be a preferable option:

• Given the new features in the platform, you don’t need to build programmatic workflows. These new features are covered shortly.
• SharePoint can’t host a programmatic workflow, and it has to be deployed to Windows Azure Workflow as a non-SharePoint 2013 workflow. The developer is then on the hook to implement the communication channel between the workflow and SharePoint 2013.

From a backward-compatibility and legacy standpoint, existing SharePoint 2010 workflows can migrate to SharePoint 2013 without any problems. In addition, SharePoint 2013 workflows can call SharePoint 2010 workflows. This is a welcome feature because it allows customers to carry on with their investments in SharePoint 2010 workflows to SharePoint 2013.

Another interesting aspect of the new architecture is that Windows Azure Workflow and Service Bus are available in on-premise and in Office 365 deployments. You can use this to build your own workflow development environment. The next section covers the steps to do this.

Building Your Workflow Development Environment

Introduced as a separate download, the Windows Azure Workflow product enables customers to set up and configure a workflow farm in their on-premise deployments. You can benefit from this and build your workflow development environment the same way.

One thing to keep in mind is that you can’t install SharePoint 2013 and Windows Azure Workflow on a domain controller without some hacks. Therefore, at a minimum you need a separate server to serve as a domain controller and one server that hosts both SharePoint 2013 and Windows Azure Workflow and Service Bus.

At a high level, here are the required steps to build your workflow development environment:

1. Create a workflow service account (for example, Tailspintoys\wrkflowSvc).

2. Add the service account securityadmin and dbcreator server roles in SQL Server. It’s also part of the local administrators group.

3. Enable TCP/IP in SQL Server, which is required by Windows Azure Service Bus.

4. Log on to your SharePoint server using the workflow service account you created in step 1. This is an important step to ensure the installation wizard runs under the security context of the workflow service account.

5. Download and install Microsoft Web Platform Installer from http://www.microsoft.com/web/downloads/platform.aspx. Use this program to download and install Windows Azure Workflow and Service Bus. You need to search for Workflow 1.0 Beta.

6. Still logged on to the machine as the workflow service account, run the installation and choose Create a New Farm ⇒ Using Default Settings (Recommended), as shown in Figure 10.

FIGURE 10

a. Select Allow Workflow Management over HTTP on this Computer; otherwise, you must set up HTTPS, which is overkill for development purposes.

b. When specifying the workflow service account, use a fully qualified UPN format ([email protected]), not the default value shown in the wizard (wrkflowSvc@Tailspintoys) or NetBios name (tp\wrkflowSvc).

c. In the Certificate Generation Key and Confirm Certificate Generation Key, enter pass@word1 or another passphrase of your choice.

If everything goes smoothly, you should see a summary page like the one shown in Figure 11.

FIGURE 11

7. Log off and log back in using the farm account.

8. Pair your SharePoint farm with the workflow farm by executing the following PowerShell script. In this script the parameters are important:

a. –SPSite specifies the endpoint for the workflow farm to communicate to SharePoint. There can be only one endpoint per web application. (The example here uses http://Tailspintoys.com/sites/workflow, but you can use whatever value is appropriate for your specific needs.)

b. –WorkflowHostUri specifies the endpoint for SharePoint to communicate to the workflow farm. (Replace mydevserv with your own values.)

c. –AllowOAuthHttp specifies HTTP is allowed for OAuth calls, which is fine for development purposes, but you don’t want to use HTTP for authentication.

Register-SPWorkflowService –SPSite "http://Tailspintoys.com/sites/workflow" –
WorkflowHostUri "http://mydevserv:12291" –AllowOAuthHttp

9. Configure Active Directory Synchronization in User Profile Service Application. Windows Azure Workflow looks up the UserPrincipalName (UPN) attribute of the user from the User Profile Service Application to validate and ensure the user has enough rights to start a workflow.

At this point Windows Azure Workflow and Service Bus have been successfully installed, and the SharePoint 2013 farm and workflow farm have been successfully paired. Now, you should crack open SharePoint Designer to create a new SharePoint 2013 workflow, as shown in Figure 12.

FIGURE 12

SharePoint Designer 2013 Workflows

SharePoint Designer 2013 offers two authoring and customization experiences for developers and power users:

• Text-based designer — This is the improved version of the designer canvas. For example, you select multiple objects in the workflow design canvas and copy and paste them within the same workflow or across workflows. Interestingly enough, this was the #1 requested feature by SharePoint Designer customers.
• Visual designer — This is a new design canvas available when Visio 2013 is installed alongside SharePoint Designer 2013.

You can switch between the designers by clicking on the Views button on the Ribbon. Figure 13 shows the new visual designer.

FIGURE 13

In Figure 13, note the Visio shapes in the left pane. Also, note how you can modify the properties of workflow actions (for example, Log to History List) directly within the visual designer. You can set all the properties by selecting the shape and then clicking the action tag that appears on the left-bottom corner of the shape. If you click Properties on the action tag, the property grid for conditions and actions appears in the visual designer just as they do in the text-based designer.

Aside from the design canvas improvements, SharePoint Designer 2013 now supports new top-level containers and actions. Here are a few important ones:

• Loops — A new top-level container; as its name implies, a loop is a container that groups together actions, conditions, and steps that you want to process repeatedly. The iteration logic in a loop can be fixed (n times) or dynamic (based on a condition or expression).
• Stages — As discussed earlier, declarative workflows have been notoriously serial in nature in the previous versions of SharePoint. They have a starting point and endpoint, everything runs sequentially, and everything processes forward. In SharePoint Designer 2013, a new top-level container called stage lets you group together actions, conditions, or steps to have them executed in the listed order. After the control reaches to the end of the stage (the gate), it transitions via a Go To action to any other stage in the workflow.
  NOTE You can insert a condition in the Go To transition gate and move the control from one stage to another until the logic concludes that the workflow has completed. That means declarative workflows in SharePoint 2013 no longer need to be sequential and can be used to model state machine workflows as well.
• Calling SharePoint 2010 list and site workflows — SharePoint Designer 2013 enables SharePoint 2013 workflows to call SharePoint 2010 list and site workflows. There are two new coordination actions called Start a List Workflow and Start a Site Workflow to support this. This is important for the customers who have existing investments in SharePoint 2010 workflows and want to migrate to SharePoint 2013 while keeping their workflow investments until fully migrating them at a later time. You can also use this technique to call on workflow activities not integrated into SharePoint 2013.
• Call HTTP Web Service — Calling SOAP, WCF and OData-compliant services is now supported within declarative workflows. There is a new action named Call HTTP Web Service to support this. The calls to the remote services are originated from where the workflow runs (Windows Azure Workflow) and the returned data is stored in workflow variables, which can be accessed by other actions in the workflow. The recommended approach to embedding custom logic and code in SharePoint 2013 workflows is to create a custom web service and use the new Call HTTP Web Service action to consume the service.

Figure 14 illustrates the new Stage concept in a SharePoint Designer 2013 workflow and how you can conditionally transition (jump) from Wait for Approval stage to Approved or Rejected stages.

FIGURE 14

Another compelling use of SharePoint 2013 workflows is in apps, which is covered in the next section.

Using Workflows in Apps

The new workflow model in SharePoint 2013 enables an interesting type of development scenario. You can now use workflows as the middle-tier host for business logic in apps.

Similar to the pluggable workflow service discussed earlier, this technique is useful for protecting the intellectual property (IP) of your business logic in an app or for handling long-running business logic that the developer wants to offload from the app. For example, if your app needs to integrate with CRM sales leads, the business logic can be encapsulated in a workflow and executed in the Windows Azure Workflow execution host.

Apps can initiate and interact with declarative workflows using a new workflow JavaScript Object Model (JSOM). JSOM enables an app to deploy workflow definitions to both an App Web and a Parent Web.